Synopsis: Readable Passwords

Let’s suppose you receive a phone call from a man using one of the applications you support. The caller is having trouble logging in.

“This is Pat Johnson in Sales. I must have forgotten my password. Can you just look it up and tell me what it is?” Pat sounds a bit sheepish but also strangely in a hurry.

“I’m sorry, I’m not supposed to do that,” you answer. “I can reset your account, and that’ll send an email to the address you registered for your account. You can use the instructions in that email to set a new password.”

The man becomes more impatient and assertive. “That’s ridiculous,” he says. “At my last company, the support staff could look up my password. Are you unable to do your job? Do you want me to call your manager?”

Naturally, you want to preserve a smooth relationship with your users, so you run an SQL query to look up the plain-text password for Pat Johnson’s account and read it to him over the phone.

The man hangs up. You comment to your co-worker, “That was a close call. I almost had an escalation from Pat Johnson. I hope he doesn’t complain.”

Your co-worker looks puzzled. “He? Pat Johnson in Sales is a woman. I think you just gave her password to a con artist.”

Objective: Recover or reset passwords#

It’s inevitable that this or the other user of any application will forget their password at some point. Most modern applications handle this by giving the user a chance to recover or reset their password through an email feedback mechanism. This solution depends on the user having access to the email address associated with the user profile in the application.

Legitimate uses of the antipattern#

In such cases as when our application may need to use a password to access another third-party service — that is, our application could be a client — we would need to store that password in a readable format. Preferably, we would use some encoding that our application can reverse instead of using plain text in the database.

Here, we should make a distinction between “identification” and “authentication”. A user can identify themselves as anyone they want, but authentication is the process of making sure that the user is who they say they are. Passwords are the most common way of doing this.

Ethics of software development

If we can’t enforce a strong enough security to defeat skilled and determined attackers, then we effectively have an identification mechanism but not a reliable authentication mechanism. But this isn’t necessarily a deal-breaker.

Not every software application is at risk of attack, and not every application contains sensitive information that must be protected. For example, an intranet application may be accessed by only a few people who are known to be honest and cooperative. In this case, an identification mechanism may be enough for the application to work, and in such informal environments, a simpler login design may be adequate. The additional work necessary to create a strong authentication system may not be justified.

We must be careful, though — applications have a tendency to evolve beyond their original environment or role. Before we make our small intranet application available outside our company firewall, we must get a qualified security expert to evaluate it.